<!--#if expr="$FAQMASTER" -->
 <!--#set var="STANDALONE" value="" -->
 <!--#set var="INCLUDED" value="YES" -->
 <!--#if expr="$QUERY_STRING = TOC" -->
  <!--#set var="TOC" value="YES" -->
  <!--#set var="CONTENT" value="" -->
 <!--#else -->
  <!--#set var="TOC" value="" -->
  <!--#set var="CONTENT" value="YES" -->
 <!--#endif -->
<!--#else -->
 <!--#set var="STANDALONE" value="YES" -->
 <!--#set var="INCLUDED" value="" -->
 <!--#set var="TOC" value="" -->
 <!--#set var="CONTENT" value="" -->
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Apache Server Frequently Asked Questions</TITLE>
 </HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY
  BGCOLOR="#FFFFFF"
  TEXT="#000000"
  LINK="#0000FF"
  VLINK="#000080"
  ALINK="#FF0000"
 >
  <!--#include virtual="header.html" -->
  <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
  <P>
  $Revision: 1.1 $ ($Date: 1999/06/24 15:02:52 $)
  </P>
  <P>
  The latest version of this FAQ is always available from the main
  Apache web site, at
  &lt;<A
       HREF="http://www.apache.org/docs/misc/FAQ.html"
       REL="Help"
      ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
  </P>
<!-- Notes about changes:                                           -->
<!--  - If adding a relative link to another part of the            -->
<!--    documentation, *do* include the ".html" portion.  There's a -->
<!--    good chance that the user will be reading the documentation -->
<!--    on his own system, which may not be configured for          -->
<!--    multiviews.                                                 -->
<!--  - When adding items, make sure they're put in the right place -->
<!--    - verify that the numbering matches up.                     -->
<!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
<!--    correctly in a reliable way when this is converted to text  -->
<!--    with Lynx.  Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL>    -->
<!--    blocks inside a <P></P> instead.  This is necessary to get  -->
<!--    the horizontal and vertical indenting right.                -->
<!--  - Don't forget to include an HR tag after the last /P tag     -->
<!--    but before the /LI in an item.                              -->
  <P>
  If you are reading a text-only version of this FAQ, you may find numbers
  enclosed in brackets (such as &quot;[12]&quot;).  These refer to the list of
  reference URLs to be found at the end of the document.  These references
  do not appear, and are not needed, for the hypertext version.
  </P>
  <H2>The Questions</H2>
<OL TYPE="A">
<!--#endif -->
<!--#if expr="$TOC || $STANDALONE" -->
 <LI VALUE="7"><STRONG>Authentication and Access Restrictions</STRONG>
  <OL>
   <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
        working correctly?</A>
   </LI>
   <LI><A HREF="#user-authentication">How do I set up Apache to require
        a username and password to access certain documents?</A>
   </LI>
   <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access
        to certain documents only if a site is either a local site
        <EM>or</EM> the user supplies a password and username?</A>
   </LI>
   <LI><A HREF="#authauthoritative">Why does my authentication give
        me a server error?</A>
   </LI>
   <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL)
        authentication information on the same machine?</A>
   </LI>
   <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A>
   </LI>
   <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
        for Web page authentication?</A>
   </LI>
  </OL>
 </LI>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
</OL>

<HR>

  <H2>The Answers</H2>
<!--#endif -->
<!--#if expr="! $TOC" -->
  <H3>G. Authentication and Access Restrictions</H3>
<OL>

 <LI><A NAME="dnsauth">
      <STRONG>Why isn't restricting access by host or domain name
      working correctly?</STRONG>
     </A>
  <P>
  Two of the most common causes of this are:
  </P>
  <OL>
   <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
    registration</STRONG>
    <BR>
    This happens frequently: your configuration restricts access to
    <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
    The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
    actually an alias for another name, and when Apache performs the
    address-to-name lookup it's getting the <EM>real</EM> name, not
    <SAMP>Host.FooBar.Com</SAMP>.  You can verify this by checking the
    reverse lookup yourself.  The easiest way to work around it is to
    specify the correct host name in your configuration.
   </LI>
   <LI><STRONG>Inadequate checking and verification in your
    configuration of Apache</STRONG>
    <BR>
    If you intend to perform access checking and restriction based upon
    the client's host or domain name, you really need to configure
    Apache to double-check the origin information it's supplied.  You do
    this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
    <SAMP>EXTRA_CFLAGS</SAMP> definition in your
    <SAMP>Configuration</SAMP> file.  For example:
    <P>
    <DL>
     <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
     </DD>
    </DL>
    <P></P>
    <P>
    This will cause Apache to be very paranoid about making sure a
    particular host address is <EM>really</EM> assigned to the name it
    claims to be.  Note that this <EM>can</EM> incur a significant
    performance penalty, however, because of all the name resolution
    requests being sent to a nameserver.
    </P>
   </LI>
  </OL>
  <HR>
 </LI>

 <LI><A NAME="user-authentication">
      <STRONG>How do I set up Apache to require a username and
      password to access certain documents?</STRONG>
     </A>
  <P>
  There are several ways to do this; some of the more popular
  ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>,
  <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or
  <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules.
  </P>
  <P>
  For an explanation on how to implement these restrictions, see
  <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s
  articles on
  <A HREF="http://www.apacheweek.com/features/userauth"
  ><CITE>Using User Authentication</CITE></A>
  or
  <A HREF="http://www.apacheweek.com/features/dbmauth"
  ><CITE>DBM User Authentication</CITE></A>.
  </P>
  <HR>
 </LI>

 <LI><A NAME="remote-auth-only">
      <STRONG>How do I set up Apache to allow access to certain
      documents only if a site is either a local site <EM>or</EM>
      the user supplies a password and username?</STRONG>
     </A>
  <P>
  Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive,
  in particular the <CODE>Satisfy Any</CODE> directive, to require
  that only one of the access restrictions be met.  For example,
  adding the following configuration to a <SAMP>.htaccess</SAMP>
  or server configuration file would restrict access to people who
  either are accessing the site from a host under domain.com or
  who can supply a valid username and password:
  </P>
  <P>
  <DL>
   <DD><CODE>deny from all
    <BR>
    allow from .domain.com
    <BR>
    AuthType Basic
    <BR>
    AuthUserFile /usr/local/apache/conf/htpasswd.users
    <BR>
    AuthName "special directory"
    <BR>
    require valid-user
    <BR>
    satisfy any</CODE>
   </DD>
  </DL>
  <P></P>
  <P>
  See the <A HREF="#user-authentication">user authentication</A>
  question and the <A HREF="../mod/mod_access.html">mod_access</A>
  module for details on how the above directives work.
  </P>
  <HR>
 </LI>

 <LI><A NAME="authauthoritative">
      <STRONG>Why does my authentication give me a server error?</STRONG>
     </A>
  <P>
  Under normal circumstances, the Apache access control modules will
  pass unrecognized user IDs on to the next access control module in
  line.  Only if the user ID is recognized and the password is validated
  (or not) will it give the usual success or &quot;authentication
  failed&quot; messages.
  </P>
  <P>
  However, if the last access module in line 'declines' the validation
  request (because it has never heard of the user ID or because it is not
  configured), the <SAMP>http_request</SAMP> handler will give one of
  the following, confusing, errors:
  </P>
  <UL>
   <LI><SAMP>check access</SAMP>
   </LI>
   <LI><SAMP>check user.  No user file?</SAMP>
   </LI>
   <LI><SAMP>check access.  No groups file?</SAMP>
   </LI>
  </UL>
  <P>
  This does <EM>not</EM> mean that you have to add an
  '<SAMP>AuthUserFile&nbsp;/dev/null</SAMP>' line as some magazines suggest!
  </P>
  <P>
  The solution is to ensure that at least the last module is authoritative
  and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is
  authoritative and will give an OK/Denied, but only if it is configured
  with the proper <SAMP>AuthUserFile</SAMP>.  Likewise, if a valid group
  is required.  (Remember that the modules are processed in the reverse
  order from that in which they appear in your compile-time
  <SAMP>Configuration</SAMP> file.)
  </P>
  <P>
  A typical situation for this error is when you are using the
  <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>,
  <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or
  <SAMP>mod_auth_cookie</SAMP> modules on their own.  These are by
  default <STRONG>not</STRONG> authoritative, and this will pass the
  buck on to the (non-existent) next authentication module when the
  user ID is not in their respective database.  Just add the appropriate
  '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration.
  </P>
  <P>
  In general it is a good idea (though not terribly efficient) to have the
  file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows
  you to access the web server with a few special passwords even if the
  databases are down or corrupted.  This does cost a
  file open/seek/close for each request in a protected area.
  </P>
  <HR>
 </LI>

 <LI><A NAME="auth-on-same-machine">
      <STRONG>Do I have to keep the (mSQL) authentication information
      on the same machine?</STRONG>
     </A>
  <P>
  Some organizations feel very strongly about keeping the authentication
  information on a different machine than the webserver. With the
  <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL
  modules connecting to (R)DBMses this is quite possible. Just configure
  an explicit host to contact.
  </P>
  <P>
  Be aware that with mSQL and Oracle, opening and closing these database
  connections is very expensive and time consuming. You might want to
  look at the code in the <SAMP>auth_*</SAMP> modules and play with the
  compile time flags to alleviate this somewhat, if your RDBMS licences
  allow for it.
  </P>
  <HR>
 </LI>

 <LI><A NAME="msql-slow">
      <STRONG>Why is my mSQL authentication terribly slow?</STRONG>
     </A>
  <P>
  You have probably configured the Host by specifying a FQHN,
  and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket
  to talk to the database, rather than a fast internal device.  The
  <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
  documentation warn you about this.  If you have to use different
  hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
  some compile time flags which might - or might not - suit you.
  </P>
  <HR>
 </LI>

 <LI><A NAME="passwdauth">
      <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
      for Web page authentication?</STRONG>
     </A>
  <P>
  Yes, you can - but it's a <STRONG>very bad idea</STRONG>.  Here are
  some of the reasons:
  </P>
  <UL>
   <LI>The Web technology provides no governors on how often or how
    rapidly password (authentication failure) retries can be made.  That
    means that someone can hammer away at your system's
    <SAMP>root</SAMP> password using the Web, using a dictionary or
    similar mass attack, just as fast as the wire and your server can
    handle the requests.  Most operating systems these days include
    attack detection (such as <EM>n</EM> failed passwords for the same
    account within <EM>m</EM> seconds) and evasion (breaking the
    connection, disabling the account under attack, disabling
    <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
    Web does not.
   </LI>
   <LI>An account under attack isn't notified (unless the server is
    heavily modified); there's no &quot;You have 19483 login
    failures&quot; message when the legitimate owner logs in.
   </LI>
   <LI>Without an exhaustive and error-prone examination of the server
    logs, you can't tell whether an account has been compromised.
    Detecting that an attack has occurred, or is in progress, is fairly
    obvious, though - <EM>if</EM> you look at the logs.
   </LI>
   <LI>Web authentication passwords (at least for Basic authentication)
    generally fly across the wire, and through intermediate proxy
    systems, in what amounts to plain text.  &quot;O'er the net we
    go/Caching all the way;/O what fun it is to surf/Giving my password
    away!&quot;
   </LI>
   <LI>Since HTTP is stateless, information about the authentication is
    transmitted <EM>each and every time</EM> a request is made to the
    server.  Essentially, the client caches it after the first
    successful access, and transmits it without asking for all
    subsequent requests to the same server.
   </LI>
   <LI>It's relatively trivial for someone on your system to put up a
    page that will steal the cached password from a client's cache
    without them knowing.  Can you say &quot;password grabber&quot;?
   </LI>
  </UL>
  <P>
  If you still want to do this in light of the above disadvantages, the
  method is left as an exercise for the reader.  It'll void your Apache
  warranty, though, and you'll lose all accumulated UNIX guru points.
  </P>
  <HR>
 </LI>
</OL>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
  <!-- Don't forget to add HR tags at the end of each list item.. -->

<!--#include virtual="footer.html" -->
</BODY>
</HTML>
<!--#endif -->
